-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add unique signatures generation to general parse results #3
base: main
Are you sure you want to change the base?
Conversation
Extend the idea of error hash signatures and use it to identify the parse results of states as well. Each state may define a set of 'signature fields' and, after the parsing is done and the data is collected, these fields will be used to identify the result set and generate a unique hash string for them. These signatures aren't necessarily related to errors, they simply represent a result. For now, the new states '_summary', '_signature_fields' and '_signature' are defined as hidden and are invisible unless the `--json-full` flag is used. This change also moves the hash generation to a common utility function. Signed-off-by: Ricardo Cañuelo <[email protected]>
Signed-off-by: Ricardo Cañuelo <[email protected]>
Signed-off-by: Ricardo Cañuelo <[email protected]>
Signed-off-by: Ricardo Cañuelo <[email protected]>
Signed-off-by: Ricardo Cañuelo <[email protected]>
Signed-off-by: Ricardo Cañuelo <[email protected]>
iiuc, I'm also wondering if we couldn't have another flag to say we didn't receive any logs from the kernel at all (not only that prompt wasn't reached) |
@helen-fornazier thanks for reviewing, answers below:
Ah, I thought I had use
That's something we can try to add yes, let me give it a spin and I'll push some more commits. |
Signed-off-by: Ricardo Cañuelo <[email protected]>
Add a state data field: linux.boot.kernel_started that will be True if the parser detects at least one line of kernel log and False if it doesn't. Signed-off-by: Ricardo Cañuelo <[email protected]>
Signed-off-by: Ricardo Cañuelo <[email protected]>
@helen-fornazier Done, check out this output for the results of your collected logs with these changes. |
nice! Looks good! If we could add a "Kernel didn't started" in the summary it would be even better |
Add a summary message for the scenario where the parser can't detect any kernel output. With this into place, the possible result cases for this state are: 1) Kernel booted ok and reached a prompt: _summary = Linux boot prompt found 2) Kernel produced no output at all: _summary = Kernel didn't start 3) Kernel started to load but didn't reach a prompt: _summary = Linux boot prompt not found Signed-off-by: Ricardo Cañuelo <[email protected]>
looks good to me, I just want to wait for this PR to be merged if you don't mind |
These changes extend the idea of hash signatures to general parse results, not only errors. This means that all states will now have a unique hash to identify their result based on a set of result fields.
For instance, the
generic_boot
state collects its key result in thebootloader.done
field, so the signature for this result is based on the name and contents of that field.The
kernel_load
state haslinux.boot.prompt
as its key result, so that field will be used to generate the hash key for the state.Summary fields have also been added to optionally show a human-readable message describing the result.
After logspec goes through a sequence of states, their signature fields will be collected and the hash signature will be generated. The summaries for each state will also be added to a list:
Example: parse a log with the
generic_linux_boot
parser:This means that the bootloader finished correctly, handed the execution over to the kernel, the kernel loaded and reached a prompt and no errors were found.
Similar example, this time the kernel didn't reach a prompt:
For logging purposes, if we're interested only in the result of the last state, we can get the last element of the
_summary
list to get the relevant message.NOTE that these signatures aren't necessarily related to errors, but to result conditions in general.